odhcpd: remove fallback DNS search domain master
authorDavid Härdeman <[email protected]>
Sat, 13 Dec 2025 19:21:44 +0000 (20:21 +0100)
committerÁlvaro Fernández Rojas <[email protected]>
Sun, 14 Dec 2025 21:19:06 +0000 (22:19 +0100)
commit1450e1e2b7ff24268dd055795548ba813e55da56
treefd6a147e8b0cc74283db26e988d1f6f28747afdd
parent5b0e5c412f6c2c6d4f95d7fc791418f2dc03d521
odhcpd: remove fallback DNS search domain

This might require some explanation :)

First, res_init() is marked as deprecated in the Linux man-pages (read: in
glibc), and has been so for a while.

Second, we use musl on OpenWrt, and what does res_init() look like in musl?

 musl/src/network/res_init.c:

int res_init()
{
return 0;
}

 musl/include/resolv.h (commit date 2011-02-12):

/* unused; purely for broken apps */
typedef struct __res_state {

OpenWrt switched to musl sometime in 2015 (from a quick search, don't
quote me on that), and res_init() hasn't worked since then.

Ok, so first I thought I might reimplement res_init(), using the glibc
implementation as inspiration.

glibc's res_init() basically has three sources of domain search data:
 1. The LOCALDOMAIN environment variable
 2. /etc/resolv.conf
 3. gethostname() followed by checking if there's at least one dot in the name

1. The environment variable won't help us, we don't have it on OpenWrt and it
would just be confusing.

2. resolv.conf seems reasonable, but note that it is typically a symlink:
/etc/resolv.conf -> /tmp/resolv.conf -> /tmp/resolv.conf.d/resolv.conf.auto

The latter is created by netifd. Where do we get iface->dns_search from? From
netifd via ubus. In addition, the resolv.conf.auto that netifd generates
includes all dns search domain and we might end up picking a random one (so if
the user has set a domain on the guest network, but not on the main network,
the former might end up being the fallback for the latter, not good).

3. gethostname() will return the hostname, which on OpenWrt is typically set to
exactly that - the hostname and not a FQDN (and this is what the UIs tell the
users to do).

In summary, all these calls to res_init() are pointless right now, and there is
no reasonable fallback once we've failed to get the info we want from netifd.

So, remove the DNS search domain fallback logic if one isn't set. It's not like
DHCPv[46] clients or hosts listening to RAs have any expectation that the
domain search list MUST be defined.

Signed-off-by: David Härdeman <[email protected]>
Link: https://github.com/openwrt/odhcpd/pull/358
Signed-off-by: Álvaro Fernández Rojas <[email protected]>
src/dhcpv4.c
src/dhcpv6.c
src/odhcpd.c
src/router.c